Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000029_owner-urn-ietf _Wed Oct 9 22:46:08 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA04154 for urn-ietf-out; Wed, 9 Oct 1996 22:46:08 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA04149 for <[e-mail]>; Wed, 9 Oct 1996 22:46:06 -0400
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA01764  (mail destined for [e-mail]); Wed, 9 Oct 96 22:46:04 -0400
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16713(1)>; Wed, 9 Oct 1996 19:45:57 PDT
Received: by golden.parc.xerox.com id <2764>; Wed, 9 Oct 1996 19:45:40 PDT
To: [e-mail]
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]> (message from Ron
    Daniel on Wed, 9 Oct 1996 09:18:08 PDT)
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[e-mail]>
Message-Id: <96Oct9.194540pdt."2764"@golden.parc.xerox.com>
Date: Wed, 9 Oct 1996 19:45:40 PDT
Sender: [e-mail]
Precedence: bulk
Reply-To: Larry Masinter <[e-mail]>
Errors-To: [e-mail]

I'm really dismayed though by the amount of narrow defensiveness
that's been shown here, though.  Every protocol has problems. I
certainly don't believe that PURLs actually solve the Internet naming
problem. People are acting like I'm saying their puppy is ugly, just
because I'm pushing on the NAPTR proposal.

> These topics are very young, so nobody has had anything to say on them
> yet. How about you?

Honestly, I don't think you can really fault me for not being vocal.

Earlier in an interchange, someone defended NAPTRs as having been the
topic of discussion of many meetings.

> Does my suggestion of using the flags field overcome your concern
> about versioning?

I didn't think you were seriously proposing that the version of NAPTR
record elements be restricted to a number between 0 and 9. What
happens when you make the 10th revision?

> Do you have any further arguments on why a version field should be
> needed when we cannot change the number, type, or order of fields in a
> DNS record once it is out there?

Oh, no! I never suggested that you needed version numbers! My problem
was that you were using tokens "dun-and-bradstreet-lookup" without any
control on the meaning of the name!

> When clients and servers are not required to understand and support all
> the N2C, N2L, ... requests?

What? Clients don't have to understand what N2C means? Or how to do
one?

> I assume you have more knowledge of the Z39.50 URL schemes than I,
> is my concern about using URL standards-track documents as the
> "registry" misplaced? What about an IMT-style registry instead?

I don't actually think the world NEEDS a large number of resolution
protocols, any more than the world NEEDS a zillion HTML tags. The only
reason why we might see all of dun-and-bradstreet-lookup and z39.50
lookup and NAPTR lookup and ISBN-Bowker-lookup is a combination of
ignorance ("oh, they already had a protocol?"), vanity ("mine! my
protocol!") and greed ("they'll have to either pay me or see my
advertising").

Allowing lots of resolution protocols and a registry is really
counter-productive. At least there's some REASON why some applications
need audio/basic and not image/gif (even though there's no good reason
why we need both image/png and image/tiff).

Why don't we just fight it out now and save everyone grief later?

Larry